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The  National  Bureau  of  Standards'  was  established  by  an  act  of  Congress  March  3,  1901. 
The  Bureau's  overall  goal  is  to  strengthen  and  advance  the  Nation's  science  and  technology 
and  facilitate  their  effective  application  for  public  benefit.  To  this  end,  the  Bureau  conducts 
research  and  provides:  (1)  a  basis  for  the  Nation's  physical  measurement  system,  (2)  scientific 
and  technological  services  for  industry  and  government,  (3)  a  technical  basis  for  equity  in  trade, 
and  (4)  technical  services  to  promote  public  safety.  The  Bureau  consists  of  the  Institute  for 
Basic  Standards,  the  Institute  for  Materials  Research,  the  Institute  for  Applied  Technology, 
the  Institute  for  Computer  Sciences  and  Technology,  and  the  Office  for  Information  Programs. 

THE  INSTITUTE  FOR  BASIC  STANDARDS  provides  the  central  basis  within  the  United 
States  of  a  complete  and  consistent  system  of  physical  measurement;  coordinates  that  system 
with  measurement  systems  of  other  nations;  and  furnishes  essential  services  leading  to  accurate 
and  uniform  physical  measurements  throughout  the  Nation's  scientific  community,  industry, 
and  commerce.  The  Institute  consists  of  a  Center  for  Radiation  Research,  an  Office  of  Meas- 
urement Services  and  the  following  divisions: 

Applied  Mathematics  —  Electricity  —  Mechanics  —  Heat  —  Optical  Physics  —  Nuclear 
Sciences  -  —  Applied  Radiation  -  —  Quantum  Electronics n  —  Electromagnetics 3  —  Time 
and  Frequency s  —  Laboratory  Astrophysics '  —  Cryogenics  \ 

THE  INSTITUTE  FOR  MATERIALS  RESEARCH  conducts  materials  research  leading  to 
improved  methods  of  measurement,  standards,  and  data  on  the  properties  of  well-characterized 
materials  needed  by  industry,  commerce,  educational  institutions,  and  Government;  provides 
advisory  and  research  services  to  other  Government  agencies;  and  develops,  produces,  and 
distributes  standard  reference  materials.  The  Institute  consists  of  the  Office  of  Standard 
Reference  Materials  and  the  following  divisions: 

Analytical   Chemistry   —   Polymers   —   Metallurgy  —   Inorganic   Materials  —  Reactor 
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THE  INSTITUTE  FOR  APPLIED  TECHNOLOGY  provides  technical  services  to  promote 
the  use  of  available  technology  and  to  facilitate  technological  innovation  in  industry  and 
Government;  cooperates  with  public  and  private  organizations  leading  to  the  development  of 
technological  standards  (including  mandatory  safety  standards),  codes  and  methods  of  test; 
and  provides  technical  advice  and  services  to  Government  agencies  upon  request.  The  Institute 
consists  of  a  Center  for  Building  Technology  and  the  following  divisions  and  offices: 

Engineering  and  Product  Standards  —  Weights  and  Measures  —  Invention  and  Innova- 
tion — •  Product  Evaluation  Technology  —  Electronic  Technology  —  Technical  Analysis 
—  Measurement  Engineering  —  Structures,  Materials,  and  Life  Safety  *  —  Building 
Environment  *  —  Technical  Evaluation  and  Application  *  —  Fire  Technology. 

THE  INSTITUTE  FOR  COMPUTER  SCIENCES  AND  TECHNOLOGY  conducts  research 
and  provides  technical  services  designed  to  aid  Government  agencies  in  improving  cost  effec- 
tiveness in  the  conduct  of  their  programs  through  the  selection,  acquisition,  and  effective 
utilization  of  automatic  data  processing  equipment;  and  serves  as  the  principal  focus  within 
the  executive  branch  for  the  development  of  Federal  standards  for  automatic  data  processing 
equipment,  techniques,  and  computer  languages.  The  Institute  consists  of  the  following 
divisions: 

Computer  Services  —  Systems  and  Software  —  Computer  Systems  Engineering  —  Informa- 
tion Technology. 

THE  OFFICE  FOR  INFORMATION  PROGRAMS  promotes  optimum  dissemination  and 
accessibility  of  scientific  information  generated  within  NBS  and  other  agencies  of  the  Federal 
Government;  promotes  the  development  of  the  National  Standard  Reference  Data  System  and 
a  system  of  information  analysis  centers  dealing  with  the  broader  aspects  of  the  National 
Measurement  System;  provides  appropriate  services  to  ensure  that  the  NBS  staff  has  optimum 
accessibility  to  the  scientific  information  of  the  world.  The  Office  consists  of  the  following 
organizational  units: 

Office  of  Standard  Reference  Data  —  Office  of  Information  Activities  —  Office  of  Technical 

Publications  —  Library  —  Office  of  International   Relations. 


1  Headquarters    and    Laboratories    at    Gaithersburg.    Maryland,    unless    otherwise    noted;    mailing    address 
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3  Part  of  the  Center  for  Radiation  Research. 
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4  Part  of  the  Center  for  Building  Technology. 
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REPORT   ON   PLANNING   SESSION   ON   SOFTWARE 
ENGINEERING   HANDBOOK 

Software  Engineering  Handbook  Planning  Committee 
R.    G.    Canning,   Chairman 
S.    L.    Stewart/   Editor 

This  report  from  a  planning  committee  sponsored  by   the 
National   Bureau  of  Standards ,    the  National   Science  Foundation, 
and   the  Association  for  Computing  Machinery  discusses   the  need 
for,   coverage  of,   and  audience  for  a   proposed  Software  Engineer- 
ing Handbook. 

Key    Words:     Programming,    quality  software,    software   engineering. 

1 . 0      INTRODUCTION 

A  planning  session  was  conducted   in   Washington,   D.    C.    on  March  4-6, 
1973,   as    the  first   step  in  what   hopefully  will   result  in  a   handbook  on 
software  engineering.      The  planning  session   was  conducted  under   the 
auspices  of  the  National   Bureau  of  Standards ,    the  National   Science  Founda- 
tion,  and   the  Association  for  Computing  Machinery. 

Participants  in   the  planning  session  included : 

Mr.  Joel   D.    Aron,    IBM  Federal   Systems  Division 

Mr.  Anthony  D'Anna,    Western  Electric 

Dr.  Edsger  W.    Dijkstra,    Technological   University  Eindhoven 

Dr.  Dennis   W.    Fife,    NBS 

Dr.  Aaron  Finerman,   Jet  Propulsion  Laboratory 

Prof.    Robert   W.    Floyd,    Stanford  University 

Mr.  John  Gosden,    Equitable  Life  Assurance  Society 

Mr.  Harry   T.    Larson,   California   Computer  Products,    Inc. 

Mr.  Charles  P.    Lecht,   Advanced  Computer  Techniques  Corp. 

Dr.  Barbara   H.    Liskov,   M.I.T.    Project  MAC. 

Dr.  Daniel    Teichroew,    University  of  Michigan 

Mr.  Richard  G.    Canning,    Canning  Publications,    Inc.     (Chairman) 

In  addition,    the  following  sponsors  were  present: 

Dr.    D.    D.    Aufenkamp,    NSF 

Mr.    Walter  Carlson,   IBM,   representing  ACM 

Mr.    S.    Jeffery,    NBS 

The  goals  of  the  workshop  were  stated  as  follows:      Define 

What  is  most   urgently  needed? 

Who   is   the   target  audience? 

What  should  be  covered  in   the  Handbook? 

Who  should   create  it? 
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What  is  most  urgently  needed? 

The  participants  identified   two  main  areas  of  concern   —  first 
principles  for  software  engineering ,   and   the  managing  of  software  engi- 
neering of  software .      The  material    should  be  based  on  an  understanding 
of  the  programmer' s  decision  process — what  decisions   the  programmer  is 
expected   to  make.      For   each  significant  decision,    the  available  alterna- 
tives should  be  identified ,   with  at  least  a   brief  discussion  of  the 
advantages  or  disadvantage  of  each  alternative.      The  discussion   should 
be  in   terms  of  general   principles   that  can  be  applied,   ones   that  have 
been   tested  in  use.      Guidelines  should  be  presented  for  using  each  of 
the  general   principles ,   along  with  examples  of  use,   and  cost-effective- 
ness  trade-offs . 

The  participants  also   felt   that   the  Handbook  should  give  recommenda- 
tions on   the  managing  of  software  engineering ,    so  as   to  provide   the 
environment   in  which   the   engineering  of  software  can  best  be  accomplished . 
This  material   should  include  first  principles  of  successful   management 
for  R&D  type  projects ,    which  can  be  applied   to  software  development 
projects.      The  material   should  also  point  out   that   the  managerial   deci- 
sions,  and   even   the  project  organization ,   can  have  a   significant   effect 
on   the  architecture  of   the  software. 

Who   is   the   target  audience? 

The   target  audience  for   the  Handbook  was  identified  in   terms  of  the 
staff  of  one  large  business  organization,   as  an  illustrative  example   — 
but   the  same   situations   exist  in  engineering  and   scientific  programming. 
In  addition   to  job  categories ,    the  current  approximate  percent  of  total 
staff  was   given  for  each  category. 

Category  Job  %  of  staff 

A  Large  system  architects  1 

B  Large  system  project  managers  1 

C  Computer  scientists    (Ph.D.s)  1 

D  Business   system  analysts   with  little 

knowledge  of  programming  10 

E  Professional   programmers ,    experienced, 

interested  in  keeping  up  with   the 
technology ,    have  initiative   to  do   self- 
training,   capable  of  recognizing   that 
others  have  already  solved  a  particular 
problem.  22 

F  Craftsmen  programmers ,   less   experienced , 

have  less  initiative,   are  less  likely   to 
recognize   that  a  problem  has  been   solved 


by  others;    willing   to  use  a   Handbook,    if 
directed.  44 

G  Dull   programmers,    with  little  or  no 

interest  or  initiative;    just  doing  a   job.    22 

In   the  next   three   to  four   years,    the   "center  of  gravity"   may  shift 
downward  from  F   toward   the  G  category ,    based  on  present   trends   in   the 
organization   under  discussion.      After   that  period  of  time,    the  F  category 
may  represent  only   22  percent  of  the   total,   and   the  G  category  44  percent. 

In  addition,    the  participants  recognized   the  growth  in   the  number 
of  users  who  perform  programming- type  functions  but  whose  job   titles 
are  not   "programmer".      These  people  include   engineers,   operations 
researchers,    etc.,    who   use  the  computer  perhaps  via   a    time  sharing 
terminal.      So  an  additional   category,    H,   might  be  added   —  the  nonpro- 
fessional  programmers. 

RECOMMENDATION :      As  far  as   the   "first  principles  of  software  engineering" 
are  concerned ,    the  main   target  audience  is   the  E  cate- 
gory. 

Material   of  interest   to  categories  A,    B,   C,   and  D,   might 
also  be  included. 

Write   the  Handbook  so   that   it  can  be  read  by   the  cate- 
gory F  people.       (Some  participants  recommended   that  F 
people  be  included  with  E  people,   as   the  main   target 
audience. ) 

The  Handbook  should  not  be  aimed  at   the  G  and  H  cate- 
gories. 

One  participant  commented   that  many  people  in   the   target  audience  may  be 
turned  off  by   the  term   ''software  engineering."      None  of  the  group  could 
estimate   the  impact  of  this  on   the  acceptance  of  the  Handbook,    should 
it   be   true.      Another  participant   suggested   that  a    "better   title"   is 
needed.      Others  favored   the  proposed   title.      There  was  no  consensus  on 
this  point. 

RECOMMENDATION :      As   far  as  managing   software   engineering  projects   is  con- 
cerned,   the  prime  audience   is   the  project  manager  with 
from  5   to   20  people  under  him.      The  Handbook  should  help 
him  get  his  job  done.      Further,   a  different  set  of 
management   techniques   is  needed  for  very  large  projects, 
employing  scores   to   hundreds  of  people.      This  audience 
probably  should  not  be  chosen  as   the  prime   target  for 
the  Handbook. 

It  was  observed   that  various  levels  of  management  between  project 
management  and   top  management  perhaps  unknowingly  can  impose  undesirable 
pressures  or  constraints   that   influence  system  architecture.        Manage- 
ment selects   the   approach,    the  programming  languages ,    the  installation 
standards ,    the   measures ,    and   the  project   organization.      By   default, 


management  may  become  the  system  architect.  One  of  the  goals  of  the 
Handbook  should  be  to  make  the  several  levels  of  management  aware  of 
these  architecture-influencing  decisions. 

2.0      GENERAL   DISCUSSION   OF   CONTENTS 

2.1  Potential    Breadth  of  Subject 

The  creation  of  a   new  software-using  system  involves  many  components 
beyond   the   software  itself.      These  components  include   the  hardware, 
programs  for   the   hardware,   people,   and  procedures  for   the  people.      The 
ways  in  which   these  components  are  used  are  influenced  by  the   technology , 
by  financial   considerations ,   by  inter-organizational   politics,   and  by 
intra-organization  psychology.      In   theory,    the  Handbook  could  address 
this  whole  subject  area. 

The  types  of  decisions  involved  in  creating  a  new  software-using 
system  includes  those  on  the  software  (make  or  buy) ,  the  hardware 
(selecting  major  components ,  selecting  minor  components,  etc.),  pro- 
cedures ("operator"  procedures,  interfacing  with  other  systems,  etc.) 
and  people.  Also,  the  scope  of  the  software  must  be  defined;  it  can 
include  source  code,  object  code,  documentation,  firmware ,  logic  em- 
bedded  in   LSI  chips,    and  so   on. 

RECOMMENDATION:      It   was   the  consensus  of   the   group   that    the  Handbook 
not  be  concerned  with  all   of  these  aspects,   as   im- 
portant as   they  may  be   to   the  overall    success  of  the 
new  system. 

Instead,    the  Handbook  should  be  concerned  with  computer 
program  design,   construction,   and  quality  assurance. 
Computer  programs  include  both  software  systems  and 
application  programs. 

2.2  Potential   Depth  of  Coverage 

It  would  not  be  desirable   to  aim   the  Handbook  at   too   low  a   level   of 
capability.      There   should  be  no   implication   that   "anybody  can  be  a 
software  engineer  by   using  this  Handbook." 

At   the  same   time,    it  is  recognized   that   the  majority  of  today's 
practicing  programmers  received   their  original   programming  training 
from  computer  manufacturer  or  employer   training  courses   —  at  least, 
of  the  F  and  G  level   programmers.      Only  a   small   percentage  have  received 
computer   science  education  at   the  masters,   or   even  bachelors,  level . 

The  major  portion  of  the  software  engineering  portion  of  the 
Handbook  should  be  addressed   to   the  level   E  professional   programmer , 


as   roughly   defined  above.      As   mentioned  previously ,    the  Handbook  should  be 
understandable  by   the   level   F  programmers .      While  some   of   the  material   can 
be   addressed   to   the   levels   A,   B,   C,    and  D,   such  material  probably  should 
be   clearly  identified  as   for   those   audiences . 

2.3  Kinds   of  Programs 

A   variety   of  kinds   of  computer  programs   were  identified  for  which   the 
first  principles    discussed  in    the  Handbook  would  apply.      These  included 
applications   software    (scientific,    engineering ,  business ,   military ,   space 
and  process   control)  ,   and  systems   software    (operating  systems,    compilers , 
assemblers ,    data  management,   etc.).      Further,    the  systems   software  might 
be   developed  for  an   existing  machine,   or  for  a  machine  which   itself  is 
still    under  development. 

RECOMMENDATION :      The   same   general    design    techniques    can  be    used  for  both 
application  software   and  systems  software .      However,    the 
design   decisions   can  be  more   complex  for  large  systems 
of  either  type. 

Two   types   of  computer  programs   were   identified  for  which   the 
principles   discussed  in   the  Handbook  probably  would  not  apply.      These 
were:      hybrid  computation  programs ,    and  ad  hoc  problem  solving  programs 
which  would  be   used  only  one   or   two   times. 

2.4  Desired  Changes   in   Tools 

It  was  contended   by   one  participant   that   the  programming  language 
used  for  a   given  program,   or  set  of  programs,   influences    the  way   the 
programmer  conceives    the  program  design.      It  was   further  contended  that 
the   most  popular  existing  languages — FORTRAN,    COBOL,    and  ALGOL   60 — exert 
undesirable    types   of  influence   and  are  not   appropriate   vehicles   for 
guiding  the  programmer' s    thought.      Further,    the  largest   gains   from 
software   engineering  will   come   from  using  more   appropriate  primitives . 
It  was   felt   that  the  Handbook  should   try    to  force  such  needed  changes. 

It  was  further  contended  that  it  will  be  difficult  to  find  language- 
independent  first  principles  for  program  design.  The  programming  language 
that  is    used  permeates    the   design. 

There  was  not  a   consensus   on   these   contentions .      In   rebuttal    to   them, 
it  was   argued  that  perhaps   90  percent   of  the   first  principles   of  program 
design   are   language-independent .      Further,   regardless   of  opinions   about 
the  existing  languages ,    the   fact   remains   that   they  will   continue   to  be 
used  for   the  bulk  of  the  programming  for  some   years    to   come.      The  engi- 
neering of  software  must   take  into  account   that   these   languages   will  be 
widely   used. 

The   question   of  how  strongly   the  Handbook  should  press   for  signifi- 
cant  changes   in    the   tools    thus   did  not   get   answered  at   this   meeting. 


3.0      POTENTIAL  STRUCTURING   OF   THE   HANDBOOK 

The  participants  saw   the  structure   of  the  Handbook  as   consisting  of 
three  main   sections :      rationale   for   using  the  Handbook    (about   one  percent 
of  the   total  pages)  ,   managing  the   engineering  of  software    (about  nine 
percent   of  the    total  pages)  ,    and  software   engineering    (about  90  percent  of 
the    total  pages) . 

The  first  section  would  include  not   only   the  rationale  for  using  the 
Handbook  but   also   the   goals   of  the  Handbook ,  how  to  use  it,   and  criteria 
for  making  design   decisions .       (One  participant  believes    that   one  percent 
of  the   total  pages   is  not  enough   for   this   section. ) 

The  section   on  managing  software  engineering  should  include   the   "time 
structure"    of  a  software  project,    and  first  principles   of  successful 
management   of  projects   of  this   type.      There  was   mixed  opinion   as   to  whether 
professional   responsibility   and  ethics   should  be  included. 

The  software   engineering  section  was   viewed  as   consisting  of  three 
parts.      One  would  be   the  architecture  part,   dealing  with    the  highest   level 
design   decisions .      Next  would  be   the  engineering  part,   the  next   level    of 
design   decisions ,   wherein   the    technology   is    used  to  achieve  a   design   that 
meets    the  postulated   criteria.      Finally,    there  would  be   the   construction 
part,   involving  the   lowest   level   of  design   decisions ,   such   as   the  details 
of  program  segmentation.      Further  details   on   this  section   are  included  as 
an  Appendix. 

4.0      THE   NEXT   STEPS 

A  brief  discussion  was   conducted  on  how  best    to  proceed  with    the 
Handbook  project.      While  a  number  of  suggestions  were   advanced ,    there  was 
no  consensus   on  how  best   to  proceed.      This   subject   really  was   outside   of 
the  charge   of  this  planning  meeting;    the  meeting  was    to  concentrate  on   the 
problem  definition   stage  of  the  Handbook  project,   involving  the  aspects   of 
what  and  who ,    rather   than   how. 

Since  no  consensus  was    reached ,    and  since    the  sponsoring  organizations 
had  representatives   in   attendance,   it  was   agreed  that    these   representatives 
would  decide   on   the  plan   of  action   for   the  next  steps,  based  on   the 
recommendations   made  in   this   report. 
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APPENDIX   I.       SPECIFIC  SUGGESTIONS   FOR   SOFTWARE   ENGINEERING    TECHNIQUES 
CONTENTS 


System/Program/ Pat  a  Architecture 

Deals  with   defining  the   overall  structure. 

Involves  selection   of  an   architecture. 

Present  survey  of  theories   on  program  structuring  and  examples   of 
how   to  use   them;    for  instance,    with   combinatorial    type  problems , 
structure  so  that    the  number  of  cases   adds   rather   than  multiplies. 

Present   guidelines   for  modularizing  system,  programs,   and  data  so 
as   to  minimize   chances   of  errors.      Minimize    the  number  of  inter- 
connections between  modules. 

Present   concepts   of  structured  programming  and  proof  of  correctness . 

Present  survey  of  useful   abstraction  patterns   and  the   various   forms 
found  in   computer  programs ,   including  parallelism. 

Codify    the   constraints  where   the  architect  may  have   little   or  no 
freedom  of  choice    (as   in    the   case  of  the  hardv/are  ,   or  operating 
system)  . 

The   data  must  be  structured ,   as  well   as    the  system  and  the  programs. 
Includes  both   file  structuring  and  data  base  structuring.      Show 
relationships  between   data  modules   and  program  modules. 

System/Program/Data  Engineering 

Discuss   criteria  for  judging  a   design:      maintainability ,    utility, 
effectiveness  ,    availability ,    resilience ,   extensibility  ,    defensive 
design,   modifiability,   economics  ,    understandability ,    transferability , 
reliability  ,   simplicity  ,    generality  ,   and  flexibility . 

Promote    the   understanding  of:      modularity ,    design   methodology,   effect 
of  scale    (magnitude)    of  projects ,    the  desire   for  quality  software   as 
opposed   to  acceptable  software ,   identifying  hardware   design   features 
that  result  in   unresolvable   conflicts   for   the  software ,   and  the 
ability    to  judge  a  priori   if  particular  tools   will   apply    to  a  job, 
and  how  well. 

Discuss    use  of  models   and  quantitative   techniques   for  making  design 
decisions . 


Discuss   quality   assurance.      With   regular  design,   involves   a   test 
plan   developed  at   the  outset.      With   structured  programming ,   involves 
proof  of  correctness ,   where   testing  and  integration   occur   throughout 
construction ,   and  not   after  it. 

Discuss   ways   to  adapt   to  changes   in  system  specifications ,   providing 
for  change  in   original   design   via  scaffolding;    use   of  configuration 
control   and  formal   change   control;    repair  and  maintenance;   patching. 

System/Program/Data   Construction 

List   of  available    tools: 

Languages — benefits   and  drawbacks   of  particular  languages , 
including  data  manipulation   and  data   descriptive 
languages ;  how  to   choose   a   language ;   some   tricky 
features   of  common  programming  languages . 

Operating  systems — benefits   and  drawbacks;   if  choice   is 
available ,   how   to   choose   an   operating  system. 

Data  base  management  system — same  as   operating  systems. 

Testing  aids. 

Construction   aids. 

List   of  available   techniques ,   including  pros   and  cons   of  each: 

Sorting  techniques 

Data   compression;   data   coding 

Searching 

Validation    techniques 

Queuing 

Paging 

Segmentation 

Parsing 

Listing  processing 

Query  processing 

Translation   techniques — compilation ,   interpretation ,    generation 


Implicit   versus   explicit  data  definitions 

Survey   of  program  construction   techniques ,   with  examples ; 
example:      use   of  "superfluous"    code   for  mapping  problem  into 
more  manageable   form. 

Display    technology 

Benchmarking 

Concurrent  processing 

How   to  interact  in   multi-programming  environment 

Effect  on   design   of  various    construction    techniques 

Instrumentation,   monitoring 

Use   of  models   for  estimation   of  resources   required  and  for 
making  design   trade-offs . 

Hashing  methods 

Overlay   techniques 

Flow  charting   (as   a   design    tool,   more   than   as   a   documenta- 
tion  method)  . 

Decision    tables 

(Comment :      when  several   alternative   versions   of  a   technique 
are   available ,    as   in   the   case   of  sorting  algorithms ,   might 
present   a   decision   table   for  aiding  in    the  selection  of  the 
most   appropriate   algorithm.      In   addition ,   might  illustrate 
by   comparing  several   algori  thms  .  ) 

(Question :      how   to  discuss  proprietary    techniques ,   such   as 
automatic  flowcharters   or  program  module   test  beds?) 

List   of  standards   and  conventions,   including  documentation  standards 

National   standards   and   conventions:      ADCII ,   EBCDIC,    etc. 

Samples   of  typical    (but   good)    installation   standards 
Useful    tables 

Random  numbers 

Powers   of  2 
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Probably  exclude:      tables   of  instructions   for  particular  computers 
and/or  operating  systems. 

Question :      What   use   of  samples    of  code?      In   which   programming 
language?      (One  participant   observed   that  samples   of  code  must 
be    used   to   illustrate   first   principles    —    and   that   several   high 
level   languages   should  be    used.) 

Question :      Should   the  Handbook   teach   how   to   construct   algorithms? 

Acceptability   testing 

Test  plan  preparation 

Acceptance    testing 

Test   case   generation 

Proof  of  correctness ,   with    today's   limitations 

Volume   and  functional   test  drivers 

Test  beds   for  modules 

Systems  integrity  packages;    testing  for  no  deterioration  since 
last   update;   in  simplest   case,    a   test  problem. 

Methodology   for  desk   checking. 

Quality   assurance   of  documentation . 

(Reference  was  made  to  the  very  short  time  required  for  quality 
assurance  testing  under  the  IBM  Chief  Programmer  Team  approach, 
for   the  New  York  Times   Information  Retrieval  System.) 

Large     scale   systems 

A  chapter  perhaps  should  be  devoted   to  special   considerations 
that  must  be   given   to  the  design   and  construction   of  large 
systems . 

Concepts  involved  include: 

Autonomous   sub-systems   versus   a  man-layered  hierarchy 

Phasing  of  sub-systems 

"Creeping  commitment"    for  retaining  options   as   long  as 
possible. 
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APPENDIX  II.       SPECIFIC  SUGGESTIONS   FOR   SOFTWARE   ENGINEERING 
MANAGEMENT   CONTENTS 

The   techniques   of  managing  software  projects   are   very  similar   to   the 
techniques    used  for  managing  R&D  projects  where   the   design  has   a  high 
degree   of  uncertainty . 

Traditionally  in   the  software   field,  projects  have   ended   up  over  cost, 
over  schedule ,    and  deliver  less  performance   than  promised.      Better 
management   techniques   can  help   to  alleviate   these  problems. 

First  Principles   of  Managing  Software  Projects 

Define   the  problem  to  be  solved  at   the   outset;   state   the  system 
requirements   in   a   language   that  is    understandable  by   the   users; 
get    user  management   approval   of  these   requirements   and  problem 
statement. 

Make   the   design   easy   to  change;   implies   a  modular  design. 

Consider   the  idea   of  the   "creeping  commitment" ,   for  large 
projects   and/or  those  where   the   design   is    very  subject   to   change. 

Identify  alternative  solutions ,    then  select   the  best   of  the 
alternatives   according  to  criteria. 

Quality   assurance  should  not  be  separated  from  construction. 
Plan   the  quality   assurance  at   the  outset,    using  either  proof 
of  correctness   or  conventional    testing.      The   constructor  must 
demonstrate    that  a  module  meets   its   specifications. 

Once   the   design  selection  has  been  made,   institute  a   change   review 
and  approval  process,   so  as    to  control   changes. 

Every  software  engineer  is   a  manager,   even  if  just  of  himself. 
He  must  plan  his   activities ,    so   that  management   techniques   are 
as   appropriate   to  his  work  as   design   techniques .      He  should 
apply   first  principles    to   the   resources    under  his   control,   and 
try    to  influence  his  boss    to   use   those   first  principles .      The 
fact    that   a  particular  manager  does  not   understand   the  principles 
of  software   engineering  should  have  no  influence  on    the  profession 
of  software   engineering. 

Recognize   that   constraints   imposed  by  management   are   of  two   types — 
mandatory   and  negotiable.      Recognize ,   also,    that  some   "mandatory" 
constraints   are   really  negotiable. 

The  structure  of  a  project   organization  will  have  a   vitally  important 
effect  on    the   architecture   and  engineering  of  the  resultant  system, 
since  it  defines   the  lines   of  communications .      Both   democratic  and 
autocratic  project  structures   are  being  proposed   these   days,   with 
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some   instances   of  impressive  performance   under  autocratic  structuring. 

A   "Standard"   Project  Discipline 

Problem  definition 

Define  system 
Decompose  into  parts 
Define  parts 
Decompose  into  sub-parts 

Develop  system  specifications ,    for  new  system 

Perform  system  design   and   test   design;   institute   formal 
change  procedure 

Perform  program  design 

Perform  program  building  and  quality   assurance 

Perform  system  test   and  integration 

Perform  conversion ,    operation ,   and  maintenance 

Comment:      Project   administration   functions  would  be   conducted  in 
parallel  with   the   above  activities .      Also,   installation 
standards   should  be  employed. 

Comment:      Measures   are  needed  by  which   the  individual  programmer 
can    tell  how  much  progress  he  has  made,   and  how  much  he 
still  has   to  do,    to  finish   the  job. 

Comment:      A  reduced   version   of   the  above  project   discipline  may  be 
needed  for  small  projects ,   and   for  to-be-used-one-time- 
only  programs. 

Ques ti ons : 

Should   the  Handbook  include   guidance   for  executive  management, 
since   they   often  make   constraining  decisions?      (One  participant 
argued   that  such  material  should  be  included ,   if  at   all,   only  in 
the  opening  tutorial  section. ) 

Should  the  Handbook   address   the  question   of  training  management 
in  some   aspects   of  software  engineering? 

Should  the  Handbook   address    the  subject   of  the  professional 
responsibility   and  ethics   of  the  software   engineer? 


13 


NBS-114A    (REV.    7-73) 


U.S.   DEPT.  OF   COMM. 

BIBLIOGRAPHIC  DATA 

SHEET 


1.  PUBLICATION  OR  REPORT  NO. 

NBS   TN-832 


2.  Gov't  Accession 
No. 


3.  Recipient's  Accession  No. 


4.  TITLF  AND  SUBTITLE 

REPORT   ON  PLANNING   SESSION  ON  SOFTVIARE  ENGINEERING   HANDBOOK 


5.  Publication  Date 

November  1973 


6.  Performing  Organization  Code 


7.  AUTHOR(S) 

S.    L.    Stewart 


8.  Performing   Organ.  Report  No. 


9.  PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 

NATIONAL  BUREAU  OF  STANDARDS 
DEPARTMENT  OF  COMMERCE 
WASHINGTON.  D.C.  20234 


10.  Project  /Task/Work  Unit  No. 

640-1129 


11.  Contract/Grant  No. 


12.  Sponsoring  Organization  Name  and  Complete  Address  (Street,  City,  State,  ZIP) 


Same     as   #9 


13.  Type  of  Report  &  Period 
Covered 


14.  Sponsoring  Agency  Code 


15.  SUPPLEMENTARY  NOTES 

Library  of  Congress  Catalog  Card  Number:     74-600091 


16.  ABSTRACT  (A  200-word  or  less  factual  summary  ot  most  significant  information.     If  document  includes  a  significant 
bibliography  or  literature  survey,  mention  it  here.) 

This  report  from  a  planning  committee  sponsored  by  the  National   Bureau  of 
Standards,    the  National   Science  Foundation,   and   the  Association  for  Computing 
Machinery  discusses   the  need  for,   coverage  of,   and  audience  for  a  proposed 
Software  Engineering  Handbook. 


17.  KEY  WORDS  (six  to  twelve  entries;  alphabetical  order;  capitalize  only  the  first  letter  of  the  first  key  word  unless  a  proper 
name;  separated  by  semicolons) 

Programming,    quality  software ,    software  engineering. 


18.   AVAILABILITY  [~jc  Unlimited 

_  For  Official  Distribution.    Do  Not  Release  to  NTIS 

\_K  Order  From  Sup.  of  Doc,  U.S.  Government  Prirv«ir>«„0^fice 
Washington,  D.C.  20402,  SD  Cat.  No.  CI  3     .  46:832 

Order  From  National  Technical   Information  Service     NT  IS  l 

Springfield,  Virginia  22151 


19.  SECURITY  CLASS 
(THIS  REPORT) 


UNCLASSIFIED 


20.   SECURITY  CLASS 
(THIS  PAGE) 

UNCLASSIFIED 


21.  NO.  OF  PAGES 

18 


22.  Price 

70   cents 

USCOMM.DC    29042-P74 


NBS  TECHNICAL  PUBLICATIONS 


PERIODICALS 
JOURNAL  OF  RESEARCH  reports  National  Bureau 
of  Standards  research  and  development  in  physics, 
mathematics,  and  chemistry.  Comprehensive  scientific 
papers  give  complete  details  of  the  work,  including 
laboratory  data,  experimental  procedures,  and  theoreti- 
cal and  mathematical  analyses.  Illustrated  with  photo- 
graphs, drawings,  and  charts.  Includes  listings  of  other 
NBS  papers  as  issued. 

Published  in  two  sections,  available  separately: 

•  Physics   and   Chemistry    (Section    A) 

Papers  of  interest  primarily  to  scientists  working  in 
these  fields.  This  section  covers  a  broad  range  of  physi- 
cal and  chemical  research,  with  major  emphasis  on 
standards  of  physical  measurement,  fundamental  con- 
stants, and  properties  of  matter.  Issued  six  times  a 
year.  Annual  subscription:  Domestic,  $17.00;  Foreign, 
521.25. 

•  Mathematical  Sciences   (Section   B) 

Studies  and  compilations  designed  mainly  for  the  math- 
ematician and  theoretical  physicist.  Topics  in  mathe- 
matical statistics,  theory  of  experiment  design,  numeri- 
cal analysis,  theoretical  physics  and  chemistry,  logical 
design  and  programming  of  computers  and  computer 
systems.  Short  numerical  tables.  Issued  quarterly.  An- 
nual subscription:   Domestic,  $9.00:   Foreign,  $11.25. 

DIMENSIONS/NBS  (formerly  Technical  News  Bul- 
letin)— This  monthly  magazine  is  published  to  inform 
scientists,  engineers,  businessmen,  industry,  teachers, 
students,  and  consumers  of  the  latest  advances  in 
science  and  technology,  with  primary  emphasis  on  the 
work  at  NBS. 

DIMENSIONS/NBS  highlights  and  reviews  such 
issues  as  energy  research,  fire  protection,  building 
technology,  metric  conversion,  pollution  abatement, 
health  and  safety,  and  consumer  product  performance. 
In  addition,  DIMENSIONS/NBS  reports  the  results  of 
Bureau  programs  in  measurement  standards  and  tech- 
niques, properties  of  matter  and  materials,  engineering 
standards  and  services,  instrumentation,  and  automatic 
data  processing. 

Annual  subscription:  Domestic,  $6.50;  Foreign,  $8.25. 

N0NPERI0DICALS 

Monographs — Major  contributions  to  the  technical  liter- 
ature on  various  subjects  related  to  the  Bureau's  scien- 
tific and  technical  activities. 

Handbooks — Recommended  codes  of  engineering  and 
industrial  practice  (including  safety  codes)  developed 
in  cooperation  with  interested  industries,  professional 
organizations,  and  regulatory  bodies. 
Special  Publications — Include  proceedings  of  high-level 
national  and  international  conferences  sponsored  by 
NBS,  precision  measurement  and  calibration  volumes, 
NBS  annual  reports,  and  other  special  publications 
appropriate  to  this  grouping  such  as  wall  charts  and 
bibliographies. 

Applied  Mathematics  Series — Mathematical  tables, 
manuals,  and  studies  of  special  interest  to  physicists, 
engineers,  chemists,  biologists,  mathematicians,  com- 
puter programmers,  and  others  engaged  in  scientific 
and  technical  work. 


National  Standard  Reference  Data  Series — Provides 
quantitative  data  on  the  physical  and  chemical  proper- 
ties of  materials,  compiled  from  the  world's  literature 
and  critically  evaluated.  Developed  under  a  world-wide 
program  coordinated  by  NBS.  Program  under  authority 
of  National  Standard  Data  Act  (Public  Law  90-396). 
See  also  Section  1.2.3. 

Building  Science  Series — Disseminates  technical  infor- 
mation developed  at  the  Bureau  on  building  materials, 
components,  systems,  and  whole  structures.  The  series 
presents  research  results,  test  methods,  and  perform- 
ance criteria  related  to  the  structural  and  environmen- 
tal functions  and  the  durability  and  safety  character- 
istics of  building  elements  and  systems. 

Technical  Notes — Studies  or  reports  which  are  complete 
in  themselves  but  restrictive  in  their  treatment  of  a 
subject.  Analogous  to  monographs  but  not  so  compre- 
hensive in  scope  or  definitive  in  treatment  of  the  sub- 
ject area.  Often  serve  as  a  vehicle  for  final  reports  of 
work  performed  at  NBS  under  the  sponsorship  of  other 
government  agencies. 

Voluntary  Product  Standards — Developed  under  pro- 
cedures published  by  the  Department  of  Commerce  in 
Part  10,  Title  15,  of  the  Code  of  Federal  Regulations. 
The  purpose  of  the  standards  is  to  establish  nationally 
recognized  requirements  for  products,  and  to  provide 
all  concerned  interests  with  a  basis  for  common  under- 
standing of  the  characteristics  of  the  products.  The 
National  Bureau  of  Standards  administers  the  Volun- 
tary Product  Standards  program  as  a  supplement  to 
the  activities  of  the  private  sector  standardizing 
organizations. 

Federal  Information  Processing  Standards  Publications 
(FIPS  PUBS) — Publications  in  this  series  collectively 
constitute  the  Federal  Information  Processing  Stand- 
ards Register.  The  purpose  of  the  Register  is  to  serve 
as  the  official  source  of  information  in  the  Federal  Gov- 
ernment regarding  standards  issued  by  NBS  pursuant 
to  the  Federal  Property  and  Administrative  Services 
Act  of  1949  as  amended,  Public  Law  89-306  (79  Stat. 
1127),  and  as  implemented  by  Executive  Order  11717 
(38  FR  12315,  dated  May  11,  1973)  and  Part  6  of  Title 
15  CFR  (Code  of  Federal  Regulations).  FIPS  PUBS 
will  include  approved  Federal  information  processing 
standards  information  of  general  interest,  and  a  com- 
plete index  of  relevant  standards  publications. 

Consumer  Information  Series — Practical  information, 
based  on  NBS  research  and  experience,  covering  areas 
of  interest  to  the  consumer.  Easily  understandable 
language  and  illustrations  provide  useful  background 
knowledge  for  shopping  in  today's  technological 
marketplace. 

NBS  Interagency  Reports — A  special  series  of  interim 
or  final  reports  on  work  performed  by  NBS  for  outside 
sponsors  (both  government  and  non-government).  In 
general,  initial  distribution  is  handled  by  the  sponsor; 
public  distribution  is  by  the  National  Technical  Infor- 
mation Service  (Springfield,  Va.  22151)  in  paper  copy 
or  microfiche  form. 

Order  NBS  publications  (except  Bibliographic  Sub- 
scription Services)  from:  Superintendent  of  Documents, 
Government  Printing  Office,  Washington,  D.C.  20402. 


BIBLIOGRAPHIC  SUBSCRIPTION  SERVICES 


The  following  current-awareness  and  literature-survey 
bibliographies  are  issued   periodically   by   the  Bureau: 

Cryogenic  Data  Center  Current  Awareness  Service 
(Publications  and  Reports  of  Interest  in  Cryogenics). 
A  literature  survey  issued  weekly.  Annual  subscrip- 
tion:  Domestic,   $20.00;   foreign,  $25.00. 

Liquefied  Natural  Gas.  A  literature  survey  issued  quar- 
terly. Annual  subscription:  $20.00. 

Superconducting  Devices  and  Materials.  A  literature 
survey  issued  quarterly.  Annual  subscription:  $20.00. 
Send  subscription  orders  and  remittances  for  the  pre- 


ceding bibliographic  services  to  the  U.S.  Department 
of  Commerce,  National  Technical  Information  Serv- 
ice, Springfield,  Va.  22151. 

Electromagnetic  Metrology  Current  Awareness  Service 

(Abstracts  of  Selected  Articles  on  Measurement 
Techniques  and  Standards  of  Electromagnetic  Quan- 
tities from  D-C  to  Millimeter-Wave  Frequencies). 
Issued  monthly.  Annual  subscription:  $100.00  (Spe- 
cial rates  for  multi-subscriptions).  Send  subscription 
order  and  remittance  to  the  Electromagnetic  Metrol- 
ogy Information  Center,  Electromagnetics  Division, 
National   Bureau  of  Standards,  Boulder,  Colo.  80302. 


U.S.  DEPARTMENT  OF  COMMERCE 
National  Bureau  of  Standards 

Washington.  DC.  20234 


OFFICIAL  BUSINESS 

Penalty  for  Private  Use.  $300 


POSTAGE  AND  FEES  PAID 

U.S.  DEPARTMENT  OF  COMMERCE 

COM-21  5 


'■^6-i9i6 


1298 


